Model-Based Software and Systems Development

The construction of reliable (embedded) software can be significantly improved using explicit model-based tool-supported development process. Research results suggest that such a process can contribute essentially to increase the quality of the developed product as well as to better efficiency of the development itself: • [Jon91] shows that more than 50 % of serious errors are made during design (25 % during implementation); about 30 % of medium class errors are made during design (30 % during implementation) • [Jon91] shows that analytical techniques performed on early-phase description of the product (e.g., structured approaches, design reviews) require generally at least less than 50 % of the effort in both error detection and correction needed for later-phase techniques (e.g., integration test, field test) • [Jon91] shows that those analytical techniques of the early phases are at least twice as effective to detect errors of the early phases than those later-phase techniques. • [BMJ+96] shows that especially in a development process requiring a high level of product quality, CASE support can significantly increase productivity. Therefore, in order to improve both the efficiency of the development process (by increasing the degree of mechanization), and the quality of the development product (by decreasing the amount of possible defects), support for a model-based development for embedded systems should go beyond the following forms of methodological and CASE tool support (see also [SHH+03]): • Using an implementation-level model: Modeling the system at implementation level rather than at a more abstract level leads to a limited development process, focusing on the implementation and integration phase. Thus, e.g., defect analysis is limited to implementation level defects. This excludes simple defects like message interface incompatibility between processes executed on different nodes since those messages are described as a byte-block oriented bus-protocol. Furthermore, due to the gap between the earlier phases and the implementation level, even design specifications are not always related to the implementation. This is often leading to inconsistencies between the design and the implementation. • Using an OO-model for embedded software: OO-based approaches supply different views of the system including non-executable views supporting early phases (e.g., use case description, interaction scenarios) making consistency analysis available in those phases. However, those views offer only limited abstraction from the OO operational model; e.g., (synchronous) method calls are used to model interaction between tasks rather than the more suitable message-or signal-based communication. Furthermore, additional domain-specific aspects (e.g., bus schedules, task …